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Introduction 


*  This  presentation  addresses  systems  engineering  applying 
Agile  practices  to  non  software-centric  projects 


•  An  experience  model  created  from  a  case  study  shows  how 
the  failures  of  a  large  program  was  able  to  show  significant 
improvements  applying  specific  Agile  practices 
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Problem  Statement 


*  The  program  was  running  over  budget  and  schedules  were  not 
being  met  -  program  management  demanded  rapid  development 
techniques  -  the  current  methodology  was  not  meeting  the  needs  of 
the  sponsors 

•  The  Agile  approach  Scrum  was  selected  as  the  only  viable  solution 
for  managing  project  execution  and  implementation  to  improve 
efficiency  and  productivity.  This  approach  worked  well,  but  not 
without  some  daunting  problems. 


*  Requirements  were  slowly  evolving  and  a  product  backlog  did  not 
exist,  so  the  core  team  decided  to  field  teams  trained  in  Agile 
practices  staffed  with  self-organized  and  motivated  individuals  in  a 
series  of  short  iterations  to  create  a  product  backlog  consisting  of 
fully-developed  and  prioritized  requirements 
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The  Approach 

•  Teams  were  staffed  with  functional  and  domain  analysts,  and 
if  available,  one  developer 

•  Requirements  were  written  directly  into  a  configuration 
management  tool  by  the  team 

•  Every  requirement  included  one  or  more  success  criteria  and 
failure  conditions  to  establish  a  validation  method 

•  Iterations  were  conducted  in  4-week  (30-calendar  day) 
durations  and  ended  with  the  team  reviewing  requirements 
with  the  Product  Owner,  key  stakeholders,  and  domain 
experts 
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Industry-wide  High  Project  Failure  Rates 


•  Backward  Trend  in  Software  Project  Success 

-  Failed  and  challenged  projects  hover  around  70% 

-  High  failure  rate  due  to  inability  to  cope  with  change 

-  Big  projects  exacerbate  challenge  and  failure  potential 


•  2009  CHAOS  Standish  Chaos  Report 

-  32%  of  software  development  projects  were  successful 

-  44%  challenged 

-  24%  failed  to  meet  schedule  or  budget 


Johnson,  J.,  et  al.  (2009),  Chaos  Summary  2009,  Boston,  MA:  Standish  Group  International 


■  Successful 

■  Challenged 

■  Failed 
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Why  Aren’t  the  Successes  Higher? 

Historic  processes  were  subjected  to  the  weaknesses  of  the 
Waterfall  model.... 


The  Waterfall  Model 

•  Has  distinct  phases 

•  Lacks  feedback  loops  for  improvement 

•  Includes  sequential  phases 

•  Handoffs  to  different  teams 

•  Has  an  appealing  air  of  simplicity 

•  Project  managers  like  the  easily  tracked  milestones 
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The  Need  for  Lean  Systems  Development 


■  The  Waterfall  Model  relies  on  up-front 
requirements  and  designs  that  are: 

■  Complete 

■  Mature 

■  Sufficient 

■  Stable 


Sprint  Backlog 


Sprint 


Working  Increment 
of  Uu  software 


Copyrights  specified  as  freely  licensed  media 
http://en.wikipedia.0rg/wiki/File:Scrum_pr0cess.svg 

A  more  effective  model  is 
needed  for: 

■  Changing  requirements 

■  Incremental  development 

■  Emerging  needs 

■  Uncertainty 
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A  Viable  Alternative 
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Manifesto  for  Agile  Software  Development 


We  are  uncovering  better  ways  of  developing 
software  by  doing  it  and  helping  others  do  it. 

Through  this  work  we  have  come  to  value: 

Individuals  and  interactions  over  processes  and  tools 
Working  software  over  comprehensive  documentation 
Customer  collaboration  over  contract  negotiation 
Responding  to  change  over  following  a  plan 


That  is,  while  there  is  value  in  the  items  on 
the  right,  we  value  the  items  on  the  left  more. 


Source:  Agile  Alliance  (http://www.agilealliance.org/) 


The  Essence  of  Agile 

•  Agile  is  an  iterative  and  incremental  approach  to  the 
development  of  any  work  product 

•  Agile  is  normally  focused  on  building  software  products,  but 
some  practices  can  be  applied  to  any  project 

•  We  have  Boeing  Systems  Engineering  experience  in  developing 
requirements  and  a  Product  Backlog 

•  Agile  is  a  highly  collaborative  activity  conducted  by  self¬ 
organizing  teams  with  “just  enough”  ceremony  to 

•  produce  high  quality  products  in  a  cost-effective  and  timely 
manner 

•  meet  the  changing  needs  of  customers  and  key  stakeholders 
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Agile  Principles  and  Practices 

•  Agile  is  a  philosophy  defined  by  principles  and  practices  that  drive  quick 
delivery  of  quality  software  and  encourage  user  feedback 
•  Most  of  which  are  easily  applied  to  Agile  Systems  Engineering 


■  Customer  Satisfaction 

■  Frequent  Delivery/Deployment 

Principles:  ■  Motivated  Team 

■ 

■  Technical  Excellence 

■  Emergent  Design 


■  Embrace  Change 

■  Collaboration 

■  High  Bandwidth 

■  Sustainable  Pace 

■  Simplicity 

■  Continuous  Improvement 


■  Close  customer  collaboration  ■  Short  iterations 

■  Daily  stand-up  meetings  ■ 

Practices:  ■  ■  Prioritized  requirements 

■  ■  Product  /reviews 

■  Planning  and  estimating  ■  Self-organized  teams 


Source:  Agile  Alliance  (http://www.agilealliance.org/) 
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Scrum  Applied  to  Systems  Engineering 


•  Scrum  is  a  framework  for  managing  a  project  that  focuses  on  delivering 
the  highest  business  value  in  the  shortest  time  through  the  use  of 
simple  roles,  artifacts,  and  ceremonies 


•  A  Scrum  project  is  a  series  of  iterations  or  Sprints  where  every  2-4 
weeks  produces  fully  developed  requirements,  functional  analyses,  and 
system-level  architecture  where  decisions  are  made 

•  Teams  are  self-organized  and  fully  empowered  to  do  whatever  it  takes  to 
complete  all  iteration  work 

•  The  customer,  users,  and/or  business  needs  set  the  priorities 

•  Scrum  is  simple  and  straightforward 

•  Practices,  artifacts,  and  rules  are  few  and  easy  to  learn 

•  No  complicated  process  descriptions 

•  No  individual  assignments  -  team  selects  all  work  from  the  prioritized 
backlog 


Source:  Scrum  Alliance  (http://www.scrumalliance.org/) 
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Systems/Software  Engineering  Experience  Model 


Agile  Systems  Engineering  Activities 


Agile  Software  Development  Activities 
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Scrum  Values 


•  Scrum  is  based  on  a  set  of  fundamental  values  that  make  up  the 
backbone  of  its  practices 

•  Commitment  -  Be  willing  to  commit  to  a  goal 

-  Scrum  provides  people  all  the  authority  they  need  to  meet  their  commitments 

•  Focus  -  Do  what  you  said  you  will  do 

-  Focus  efforts  and  skills  on  doing  the  work  committed 

•  Openness  -  Everything  you  do  can  be  seen  by  everyone 

-  Scrum  is  transparent  by  keeping  everything  about  a  project  visible 

•  Respect  -  Individuals  are  shaped  by  their  experiences 

-  It’s  important  to  respect  the  diversity  of  people  who  comprise  a  team 

•  Courage  -  Have  the  courage  to  commit,  act,  be  open,  and  expect  respect 

-  Celebrate  and  enjoy  the  journey 


Source:  Scrum  Alliance  (http://www.scrumalliance.org/) 
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Why  Use  Scrum? 


•  Increases  team  productivity  and  reduces  cost  and  cycle  times 

•  Leverages  chaos 

•  Products  are  built  through  a  series  of  manageable  chunks 

•  Progress  is  made  -  even  when  requirements  are  not  stable 

•  Everything  is  visible  to  everyone! 

•  Improves  Team  communication 

•  Enables  continuous  improvement 

•  Customers  and  stakeholders  see  on-time  delivery  of  increments  and 
obtain  frequent  feedback  on  how  the  product  actually  works 

•  Establishes  a  relationship  with  customers  and  stakeholders  that 
builds  trust  and  stimulates  knowledge  growth 

•  Creates  a  culture  where  everyone  expects  the  project  to 
succeed 


Source:  Scrum  Alliance  (http://www.scrumalliance.org/) 


Slide  15 


Scrum  Works! 


*  Uses  an  iterative,  incremental  approach  to  product 
development 

*  Relies  on  interactions  between  customers,  users,  and  team 

*  Because  team  is  committed  and  focused  -  multi-tasking  is 
drastically  reduced  and  bad  multi-tasking  is  eliminated 

*  Easy  to  apply  and  implement  on  any  project  and  discipline  - 
for  example,  Agile  Systems  Engineering 
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Agile  Systems  Engineering 


Systems  Engineering  Activities 

*  Systems  engineering  includes  defined  and  repeatable 
processes  that  produce  specific  and  supportive  artifacts 

*  That  ensures  integration  with  other  Engineering 
disciplines  and  domains 

*  And  ensures  integration  among  disciplines/functions, 
design,  manufacturing,  supply  chain,  test,  product 
support,  etc. 

*  To  produce  a  system  integrated  among  all  systems  and 
components 

*  Applied  over  and  addressing  the  entire  lifecycle  of  the 
product  from  requirements  development  through  disposal 
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Key  Focus  of  Systems  Engineering 

*  Two  key  thrusts  in  program-level  systems  engineering  domains: 

*  Engineering  the  system  to  define  the  technical  solution,  and 

*  Planning  and  control  supporting  program  management 

*  Engineering  the  system  requires: 

*  Requirements  Analysis  /  Definition  /  Validation 

*  Functional  Analysis  and  Allocation 

*  Synthesis  of  Designs 

*  Evaluation  of  Alternatives 

*  Requirements  Verification 

*  Planning  and  control  requires: 

*  Organizing  and  Planning  (e.g.  Organizing  the  program,  and 
development  of  the  SEMP,  IMP/IMS) 

*  Requirements  Management 

*  Interface  Management 

*  Baseline  Management 

*  Affordability 

*  Decision  Making  (e.g.  Risk  Management,  Trade  Studies,  TPMs) 

*  Metrics  Management 

*  Reviews 
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Bridging  Agile  Principles  and  Practices  to 

Systems  Engineering 


•  The  benefits  of  experience  through  the  application  of 
common  Agile  practices  apply  well  to  systems  engineering 
activities.  That  is: 

•  Small,  self-organized  teams  producing  work  products 
incrementally  through  a  series  of  short  iterations 

•  Commitment  by  all  team  members  and  sponsors 

•  Intense  iteration  planning  sessions  that  identify  what  will  be 
completed  and  how  the  team  plans  on  completing  it 

•  Time-boxed  daily  standup  meetings 

•  Developed  requirements  and  product  backlog  are  reviewed 

•  Team  reflects  what  brought  the  highest  value  during  the  iteration 
through  a  retrospective  that  includes  the  entire  team 


•  The  Agile  systems  engineering  approach  leverages 
integrated  engineering  by  employing  the  same  vocabulary 
and  artifacts  in  an  evolving,  iterative  approach 

•  Software  and  systems  engineers  become  collaborators  that 
sincerely  consider  alternatives  and  take  actions  that  lead  to 
change 
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Agile  Systems  Engineering 


•  An  Agile  project  activity  that  defines  and  develops  requirements, 
and  creates  a  Product  Backlog  for  an  Agile  Software  Development 
project 

*  The  Scrum  framework  is  used  to  manage  project  teams 

*  The  major  difference  is  the  finished  product 

-  At  the  end  of  each  iteration,  the  Product  Backlog  “baseline” 
has  evolved  into  a  clearer  and  more  complete  set  of 
prioritized  functionality 

-  Acceptance  tests  are  written 

-  Attributes  and  constraints  are  identified 

-  Requisite  documentation  is  created  incrementally 

-  All  data  is  configuration  managed  and  controlled 

*  The  Product  Backlog  is  prioritized  by  the  Product  Owner  and 
other  domain  stakeholders,  and  made  available  to  the 
development  team 
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Product  Backlog  Example 
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Getting  Started 


•  Management,  sponsors,  and  entire  Team  must  commit 

•  Commitments  made  are  expected  to  be  fulfilled 

•  Broken  commitments  guarantee  project  failure 


•  A  good  Product  Owner  is  vital 

•  Must  have  strong  domain  knowledge 

•  Must  be  Scrum  trained 

•  Must  be  available  and  willing  to  commit 
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What  Else  is  Needed? 


•  Scrum  Master  and  Team  must  be  trained  in  Scrum 

•  Scrum  Master  facilitates  meetings,  reviews,  and 
retrospectives 

•  Development  Teams  build  software;  Requirements  Teams 
write  stories 

•  Training  is  vital  to  the  successful  execution  of  Agile  practices 

•  Insufficient  or  no  training  guarantees  project  failure 

•  Development  Teams  need  a  Product  Backlog 

•  Requirement  development  teams  build  the  Product  Backlog 

-  Consists  of  fine-grained  requirements 

-  Developers  estimate  the  size  of  each  requirement 
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Requirements  Expressed  in  Story  Format 


•  A  story  describes  functionality  that  is  valuable  to  a  customer  or 
users  of  the  system.  A  story: 

•  Provides  a  clear  and  concise  look  at  what  is  needed 

•  Is  a  unit  of  development  “work” 

•  Expresses  a  need  in  a  common  language 

•  Is  a  brief  discussion  about  the  need  that  helps  flesh  out  details 

•  Includes  tests  that  will  validate  the  need 

•  Focuses  only  on  the  size  of  the  work  -  not  how  long  it  will  take 


Storv  Example 

Storv  Template 

As  a  <  Role  > 

As  a  member  of  an  Agile  team, 

1  want  to  <  Goal  > 

1  want  to  learn  how  to  write  clear  and 
concise  stories, 

So  that  <  Reason  > 

So  that  they  possess  the  “INVEST”  attributes 
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Software/Systems  Engineering  Collaboration  Model 
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Mapping  Scrum  Practices  to  CMMI  Level  3 

•  Most  of  Scrum  maps  well  to  CMMI  Level  2  process  areas: 

•  CM:  In  an  Agile  environment,  it  is  easy  to  add  a  layer  of  CM  to  protect 
work  products  using  common  tools  and  technologies. 

•  PPQA:  Some  basic  PPQA  activities  are  being  done  naturally  when  the 
Scrum  Master  checks  or  when  QA  monitors  that  the  Scrum  process  is 
being  followed.  Other  PPQA  activities  are  completed  when  a  team 
performs  peer  reviews  and  validation. 

•  SAM:  There  are  no  practices  in  Scrum  that  deal  with  the  selection  and 
management  of  suppliers. 


•  There  are  some  limited  applications  of  CMMI  Level  3  used  in 
Scrum  including: 

•  RSKM:  Risk  management  practices  implemented  at  the  organization  or 
program  level  can  be  applied  without  much  difficulty 

•  VAL:  Validation  is  confirmed  through  formal  reviews 

•  VER:  Verification  is  performed  through  team  and  iteration  reviews 


CMMI  Levels  2  and  3  source:  http://www.sei.cmu.edu/cmmi/tools/peoplecmm/ 


Slide  27 


2- Week  Iteration  Battle  Rhythm 

*  1 0  work -day  iterations 

*  Daily  meetings/work  sessions  decided  by  the  team  - 
Day  2  through  9 

*  Iteration  Review  -  early  Day  10 

*  Retrospective  -  after  Iteration  Review  on  Day  1 0 
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Most  Important 


Project  Taskboard 


To  Do 

Checked  Out 

To  Verify 

Done!  © 

Taskl 

8 

Task  4 

13 

Task  2 
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8J 

Task  3 
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Task  6 

20j 

Task  7 

3 

Task  8 

1  1 

Task  9 

3J 
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Agile  Team  Metrics 

Provides  a  transparent  view  of  iteration  progress  and  health 


60 


1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20 


Iteration  Day 


■  Projects  that  show  consistent 
straight  lining  are  in  danger  of  not 
completing  work  by  iteration’s 
end 


■  Work  completed  significantly 
ahead  of  planned  completion  may 
indicate  additional  work  can  be 
added  to  the  iteration 
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Some  Lessons  Learned 

•  Focused,  face-to-face  iteration  sessions  improve  team  synergy 

•  Appoint  someone  to  track  time-boxed  activities 

•  Scrum  Master  should  work  with  management  to  resolve  unplanned 
organizational  impediments  that  affect  team  productivity 

•  Avoid  side  discussions  that  disrupt  team  momentum 

•  Attend  all  daily  stand-ups  (best  way  to  know  health  and  progress  of 
team) 

•  Working  as  a  team  helps  everyone  understand  tasks 

•  Team  consultations  with  domain  experts  help  clarify  ambiguity 

•  Ensure  requisite  architecture,  infrastructure,  technologies,  and  tools  are 
in  place  before  starting  team  activities  -  and  all  must  be  trained 
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QuestionsP 
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